-
Notifications
You must be signed in to change notification settings - Fork 234
chore: command orchestration #5791
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: barebones
Are you sure you want to change the base?
Conversation
|
📚 Branch Preview🔍 Visual Regression Test ResultsWhen a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:
Deployed to Azure Blob Storage: If the changes are expected, update the |
Tachometer resultsCurrently, no packages are changed by this PR... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would start
also require yarn run dev
on core?
"clean": "yarn workspaces foreach --from '@swc/*' --recursive run clean", | ||
"lint": "eslint . --ext .ts,.js,.json", | ||
"storybook": "yarn workspace @swc/components storybook", | ||
"start": "yarn workspace @swc/components storybook", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, wouldn't this also depend on core running in dev mode?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yarn start needs yarn build and yarn build will build the core as well as the second-gen/first-gen depending on what is required and that's enough to run the storybook
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but without core
running with HMR, it means changes made to any core
file won't be hot-reloaded in Storybook.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may also want to get the CEM analyzer to run in --watch
mode, because we will want getStorybookHelpers
to automatically reflect the changes to the component.
"scripts": { | ||
"build": "yarn workspaces foreach --from '@swc/*' run build", | ||
"clean": "yarn workspaces foreach --from '@swc/*' run clean", | ||
"build": "yarn workspaces foreach --from '@swc/*' --recursive run build", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will force Yarn to traverse downstream dependents, rebuilding or cleaning even when nothing changed. Is this what we need? We can do caching or parallelisation here too. Let me know your setup
"build": "yarn workspaces foreach --from '@swc/*' run build", | ||
"clean": "yarn workspaces foreach --from '@swc/*' run clean", | ||
"build": "yarn workspaces foreach --from '@swc/*' --recursive run build", | ||
"clean": "yarn workspaces foreach --from '@swc/*' --recursive run clean", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you just want to delete the SWC output you can avoid the cascading clean. You can just run this?
yarn workspaces foreach --from '@swc/*' run clean
package.json
Outdated
"build-first-gen": "yarn workspace @adobe/spectrum-web-components build", | ||
"build-second-gen": "yarn workspace @adobe/swc build", | ||
"build": "yarn build-first-gen && yarn build-second-gen", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is strictly a curiosity I had: can you explain why you chose build-first-gen
over something like build:first-gen
? I've just seen the colon syntax more often, that's all.
Sort of along these lines, if we went with the colon syntax instead, could we do something like:
"build": "yarn build:*",
Why does the order of building first-gen or second-gen matter? I honestly don't know what order something like yarn build:*
would build each project, so maybe this is not even a good idea or feasible! 😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the first part, It was an oversight on my end. I feel its better to use build:first-gen and so I switched that up. And about the second one, no the order of building first-gen or second-gen doesn't matter as long as both are being built before starting their respective storybooks.
Description
Motivation and context
Related issue(s)
Screenshots (if appropriate)
Author's checklist
Reviewer's checklist
patch
,minor
, ormajor
featuresManual review test cases
Build Pipeline (First-gen and Second-gen)
Test Scripts
Linting
Wireit Integration
CI/CD
Device review